문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 Microsoft Edge/레거시 (문단 편집) ==== 효율, 보안, 성능, 호환성 강화 ==== 기본적인 전력 효율, 보안, 성능, 호환성에 대해 지속적으로 투자했다고 한다. * 전력 효율 EdgeHTML 14에서, 자바스크립트 타이머 실행 주기를 줄이는 방식으로 백그라운드 탭 효율을 향상시켜 몇몇 경우에 90%까지 에너지 소모를 줄였다고 한다. 또한 불필요한 플래시 콘텐츠를 사용자가 클릭해 재생할 때까지 일시 정시시켜 플래시 효율정을 높였다고 한다. 그리고 플래시를 분리된 프로세스로 만들어, 플래시가 너무 많은 리소스를 쓰거나 충돌하면, 엣지가 웹사이트의 나머지 부분에 영향을 주지 않고 플래시를 끌 수 있다고 한다. [youtube(rjrxOOfi54k)] * 보안 강화 브라우저에 노출되는 커널 컴포넌트를 줄이고 플래시와 콘텐츠 프로세스에서 호출 가능한 커널 콜 리스트를 만들고 강제하는 기능인 커널 공격 보호 기능을 엣지에 탑재했다고 한다. 또한 플래시가 분리된 AppContainer에서 돌아가기 때문에 플래시 취약점과 연동된 위험들을 줄일 수 있었다고 한다. * 성능 향상 브라우저 렌더링 엔진은 몇 개의 다른 서브시스템들로 만들어지는데, 이는 각각의 페이지의 부하가 다르게 걸리게 했다. EdgeHTML 14에서, 더 빠른 경험을 위해 핵심 컴포넌트들이 더 빠르고 효율적으로 작동하게 하도록 성능을 측정하고 다듬었다고 한다. 밑의 애플과 구글에서 만든 벤치마크들에서도 엣지가 일관되게 이기고 있는 것을 볼 수 있다. [[파일:external/winblogs.azureedge.net/performance.png]] 제품의 일반적인 튜닝과 더불어, 차크라 자바스크립트 엔진에서 함수들의 메모리 최적화와 이벤트 핸들러들의 지연 파싱, 그리고 frame.contentDocument, iframe.contentWindows, scriptElement.src, requestAnimationFrame 같은 일반적인 자바스크립트 API 성능 최적화와 콜백 오버헤드 감소 같은 성능 향상을 통해 많은 잘 알라젼 프레임워크들과 코딩 패턴들에서 더 좋은 경험을 할 수 있게 되었다. 마지막으로, 키보드와 스크롤바 액션들 같은 스크롤링을 UI 쓰레드에서 완전히 분리시켜 개선했다고 한다. 이는 복잡한 페이지들이 로딩과 렌더링하느라 바쁜 와중에도 터치, 터치패드, 마우스 휠, 키보드로 문서를 스크롤할 수 있다는 것이다. * 호환성 향상 작년부터 상호 운용성(렌더링 엔진을 개발자들이 실제로 쓰고 있고 현재 유명한 브라우저들이 지원하는 "상호 운용 가능한 부분"에 대한 API를 맞추기)에 대해 집중했다고 한다. 1월부터, 마이크로소프트 엣지에서 사이트들이 "그냥 작동하도록" 자체적으로 평가를 했다고 한다. 11월의 EdgeHTML 13부터, IE11보더 현대 웹에 더 호환이 잘되어 구글 크롬과 비슷한 수준까지 올라갔다고 한다. 이 철학은 이전의 수동으로 관리되는 호환성 리스트보다 더 많은 웹 사이트에 적용할 수 있다고 한다. EdgeHTML 14에도 똑같은 방식을 적용해, 윈도우 참가자 프로그램들과 마이크로소프트 엣지 개발의 툴을 통해 받은 개발자들과 소비자들의 직접적인 피드백과 어마어마한 인터넷 스케일 데이터를 통해 같은 전략 아래에서 만들었다고 한다. [[파일:external/winblogs.azureedge.net/compatibility-1024x680.png]] Edge 14는 많은 새 HTML5 표준, 미디어 포맷, 그리고 자바스크립트 기능들을 포함해, HTML5Test에서 파이어폭스와 맞먹고, 사파리를 충실히 제치고 있다고 한다(최초 배포인 EdgeHTML 12부터). HTML5Test는 웹 플랫폼을 만드는 표준들의 부분집합의 존재 유무를 테스트하고 있다. 복잡한 벤치마크는 아니지만, 플랫폼 추이를 알 수 있고, 현대 렌더링 엔진들이 얼마나 핵심 기술들의 상호 운용 가능한 부분들을 커버하는지 알 수 있다고 한다. EdgeHTML 14의 새 기능들은 다음과 같다. * 새 HTML5 표준 * 웹 알림 API * Fetch API * 웹 인증 API (FIDO 2.0 웹 API) * 비콘 인터페이스 * {{{time}}} 요소 * {{{data}}} 요소 * {{{output}}} 요소 * {{{#input type="color"}}} * 캔버스 Path2D 오브젝트 * 웹 음성 API (합성) * 새 포맷 * WOFF 2 폰트 * Opus 오디오 재생 VP9 코덱을 포함할 수 있는 WebM 컨테이너가 지원하는 오디오 코덱 중 최신 오픈소스 오디오 코덱인 Opus를 지원하기 시작했다. 다만, Opus 오디오 코덱의 경우 MSE 활성화 설정값이 비활성이 기본이므로 about:flags 페이지에서 직접 설정해야 한다. * VP9 비디오 재생 구글이 유튜브에서 H.264의 열약한 화질을 극복하기 위하여 오픈소스로 개발한 VP9 코덱을 지원하기 시작했다. about:flags 페이지에서 VP9 코덱에 대한 MSE (Media Source Extension) 활성화 여부를 직접 설정할 수 있으며 기본값은 자동으로 되어있다. VP9를 비활성화를 해도 좋다. 하지만 VP9의 단독 해상도인 1440p HFR (고속 프레임 레이트) 및 2160p HFR은 포기해야 하고, VP9 코덱의 경우 1440p부터 H.264와 상당한 화질 격차가 날 정도로 우위를 보여준다는 점을 감안해야 한다. 참고로 VP9는 PSNR 수치를 기준으로 H.264 대비 35%의 화질 개선이 가능하고 동일 해상도에서 H.264 대비 50%의 비트레이트 절감이 가능하여 H.265와 비슷한 화질 효율성을 보여준다. VP9 코덱은 64x64와 32x32 메크로 블록 도입 및 CTU와 CU의 이원화된 비대칭 [[이산 코사인 변환|DCT]] 알고리즘을 통해 H.264의 알고리즘보다 인코딩 및 디코딩 과정이 매우 복잡하여 사양의 부담이 더 높은 편이다. 그렇다고해도 저사양에서도 CPU 빨로 VP9를 통해 1080p부터 1440p HFR (고속 프레임 레이트) 해상도까지 재생하는데에는 크게 무리가 따르지 않는다. 하지만 최신 그래픽카드가 아니라면 VP9 코덱으로 2160p HFR 및 4320P (8K) 해상도는 포기해야 한다. 더구나 H.264라고해도 최신 그래픽카드를 갖고 있지 않다면 유튜브에서 H.264로 인코딩된 8K 동영상은 상당히 벅차다. * 새 자바스크립트 기능 (기본으로 켜짐) * 기본 인수 (ES6) * 지수 연산자 (ES2016) * {{{array.prototype.includes}}} (ES2016) * {{{object.values}}}와 {{{object.entries}}} (ES2017) * 실험적 자바스크립트 기능 (about:flags에서 활성화) * 모듈 (ES6) * {{{async}}}/{{{await}}} * 정규 표현식 심볼 (ES6) * F12 개발자 툴 * 접근성 트리 뷰 * 확장 기능 디버깅 * DOM API 프로파일링저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기